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ABSTRACT 

Network layer mobility allows transport protocols to maintain con- 
nection state, despite changes in a node’s physical location and 
point of network connectivity. However, some congestion-controlled 
transport protocols are not designed to deal with these rapid and 
potentially significant path changes. In this paper we demonstrate 
several distinct problems that mobility-induced path changes can 
create for TCP performance. Our premise is that mobility events 
indicate path changes that require re-initialization of congestion 
control state at both connection end points. We present the ap- 
plication of this idea to TCP in the form of a simple solution (the 
Lightweight Mobility Detection and Response algorithm, that has 
been proposed in the IETF), and examine its effectiveness. In gen- 
eral, we find that the deficiencies presented are both relatively eas- 
ily and painlessly fixed using this solution. We also find that this so- 
lution has the counter-intuitive property of being both more friendly 
to competing traffic, and simultaneously more aggressive in utiliz- 
ing newly available capacity than unmodified TCP. 

1. INTRODUCTION 

The Internet’s routing architecture is designed to statelessly move 
packets between hosts at fixed locations. In this regime, IP ad- 
dresses provide host identifiers for network layer routing, and trans- 
port layer port number pairs are further used to identify individual 
connections between hosts. The IP addresses and port numbers 
must remain fixed for the lifetime of a connection, as the standard 
inter-layer interfaces have no mechanisms for dealing with mid- 
connection changes in a host’s address, or an application’s port 
numbers. This makes the natural approach to mobility, where a 
host’s IP address changes to represent its location, undesirable, as 
it causes existing connections to break whenever either host moves. 
For this reason, various network layer mobility schemes have been 
proposed, that extend the routing infrastructure to allow a host to 
keep a fixed address despite changes in its location. 

Several protocols exist for enabling host mobility at the network 
layer, including Mobile IPv4 (MIPv4) (22), Mobile IPv6 (MIPv6) 
[13], mobile router techniques (111 . all-IP cellular networks (5) . 
and HIP-based mobility [20] . The key feature shared by these pro- 
tocols is that a mobile node retains some fixed address (or identi- 
fier), regardless of the IP addressing structure at the point where it 
is physically attached to the network. This feature allows transport 
bindings to static addresses to remain intact, and thus keep connec- 
tions alive, despite mobility across diverse networks. In this paper, 
we show that hiding mobility events from the transport layer in this 
way can be detrimental to performance. 


In the Internet's protocol stack, the transport layer is the low- 
est layer with any view of the end-to-end network path between 
two hosts. For this reason, the transport layer is a sensible place 
to implement end-to-end congestion control, and modern transport 
protocols for bulk-traffic include congestion control mechanisms 
to perform in a manner friendly to the network and to other traffic 
[81 . Presently-used congestion control techniques such as TCP con- 
gestion control m or TCP-Friendly Rate Control (TFRC) (161 use 
packet loss events (or ECN marks) as indications of a path's con- 
gestion level, and determine their sending behavior based on packet 
losses. These techniques provide a roughly accurate estimation of 
the path’s available capacity at any given time, although TCP con- 
gestion control and TFRC differ widely in how they compute this 
estimate. 

TCP congestion control has two distinct phases, slow start and 
congestion avoidance. TCP’s slow-start algorithm quickly probes 
the amount of available capacity in a network path by doubling the 
rate it sends segments every round-trip time (RTT). This allows an 
upper bound to be quickly reached, when the first packet loss is 
detected. The steady-state congestion avoidance algorithm is used 
to keep the sending rate undulating near the rough capacity estimate 
determined during slow start. During congestion avoidance, the 
sending rate increases conservatively in a linear fashion. 



Figure 1 : Host MN moves from network N to network N’ while 
maintaining a TCP connection with host CN 


Figure [1 illustrates a mobile node, MN, moving from a connec- 
tivity point on subnet N to one on subnet N’. The mobile node 
has an active TCP connection with some correspondent node CN, 
which remains intact across the transition using a network layer 
mobility protocol, such as MIPv4. The change in MN’s attachment 
point, from subnet N to subnet N’, implies a change in the end-to- 
end path that the connection’s segments follow. Since the conges- 
tion control state (congestion window, slow start threshold, retrans- 
mission timeout, etc) of a connection is based upon estimates of the 
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end-to-end path, a path change may immediately invalidate some 
portion of the congestion control state. In figure [3], the networks 
are represented as clouds to signify that their topology is obscured 
from the end nodes, and the degree of path change is unknown. We 
assume that such mobility events occur relatively infrequently, no 
more than once per several dozen RTTs. 

Since the significance of the path change between two attach- 
ment points is a mystery, there is no way for a connection to know 
whether or not its old path property estimates from subnet N are 
reasonable in subnet N’. For example, subnet N and subnet N’ may 
be similarly configured and loaded networks who both attach to the 
Internet via a common point. In this case the difference is insignif- 
icant, and TCP's congestion state remains accurate even after the 
path change. However, there is no way of ensuring that this is the 
case, and a mobile node may just as easily move from a 54 Mbps 
802.1 lg link, to a 384 kbps cellular link. Such changes are entirely 
possible, and are currently completely hidden from the transport 
layer, so that TCP does not even get an indication from a lower 
layer that a mobility event has occurred. 

Regardless of whether or not subnet N and subnet N’ use vastly 
different media, the end-to-end paths from them to CN may have 
substantially dissimilar properties that negatively influence TCP 
congestion control. For example, a mobile node might move from 
one wireless LAN access point to another, and yet experience a 
wide variation in path properties depending upon the network load 
and number of users. In some cases, the routing between subnet N 
and CN may be via an entirely different path than from subnet N’ 
to CN. There are no guarantees about the significance or insignifi- 
cance of the path change corresponding to a mobile node’s chang- 
ing points of attachment. They may lie anywhere on the spectrum 
from trivial to severe, and TCP is left to infer and adapt on its own. 

Apart from path-dissimilarity, a mobile node’s TCP performance 
is also influenced by the underlying mobility management schemeQ. 
Broadly, the range of mobility management schemes can be classi- 
fied into two categories, soft-handoff and hard-handoff, depending 
upon whether or not packets inflight to MN’s old location on sub- 
net N are lost after movement. In the case of a hard handoff, when 
the MN moves to subnet N’, the access router in subnet N does not 
keep any state about MN’s new location. Therefore, immediately 
after subnet change, packets in flight destined to MN’s old location 
are lost. Since a full flight of loss (whether loss of data segments, 
or loss of acknowledgements) often results in an idle TCP retrans- 
mission timeout (RTO) wait period, a hard handoff results in lost 
throughput. 

With soft-handoffs, the access router in subnet N keeps a soft- 
state mapping between the mobile node’s old care-of address and 
its new address |fT4j . When a packet destined to the mobile node’s 
old address arrives, the access router in subnet N tunnels those 
packets to subnet N’, preventing losses. Because less packets are 
not lost during soft handoffs, there is less danger of a TCP retrans- 
mission timeout, but it is more likely that the mobile connection 
will temporarily behave unfairly if the new path is already con- 
gested. 

The hard/soft handoff terminology for describing network layer 
mobility support should not be confused with similar link layer ter- 
minology. In the case of the network layer, soft handoff refers to 
the old access router’s ability to forward packets to the new access 
router. In the link-layer, soft handoff refers to an interface’s ability 
to re-associate with a new link without breaking the association on 
the old link. It is possible to have both soft and hard handoffs at the 
network layer with either kind of link layer technology. 

1 Appendix lAl provides brief descriptions of several mobility man- 
agement schemes. 


Although TCP behavior is influenced by the hardness or softness 
of network layer handovers, it can have problems with both types 
of underlying protocol, simply because TCP has no mechanisms 
for dealing with the quick change of path properties presented to it. 
Some protocols route all packets through an indirection point, like 
a MIPv4 Home Agent when bi-directional tunneling is used [18}, 
while others provide a means of route optimization whereby a more 
efficient path can be used. Although these protocol features have 
some effect on the potential path change, they do not constrain it. 
Additionally, some protocols provide means for “fast” or “smooth” 
transitions. This may mitigate losses and latency during the change 
of network attachment points, making TCP have less recovery work 
to do, but it also does not limit the degree of potential difference 
in end-to-end network path properties. The exact network-layer 
mobility strategy used is mostly irrelevant to TCP, which always 
has the task of quickly adapting to a new and potentially completely 
unknown path. 

Section |2] outlines a number of problems that arise when con- 
gestion control is oblivious to mobility events. In Section [3] we 
describe a means to make network layer mobility events less trans- 
parent to TCP. We also outline a response algorithm for TCP-like 
congestion control that should address the problems described in 
this paper. The effectiveness of our approach is then evaluated in 
Section|4] and some broad discussion of the mechanism is provided 
in Section [5] 

2. MOBILITY’S EFFECT ON CONGESTION 
CONTROL 

TCP has a feedback response of increasing its congestion win- 
dow for successful transmissions, and decreasing the window for 
losses (or ECN marks). This strategy is based upon the assumption 
that future segments will traverse the same basic path as past seg- 
ments. Yet, the IP architecture provides a datagram service where 
each packet may be routed independently of all others, even when 
their sources and destinations are the same. Despite the potential 
independence in packet treatment, congestion control algorithms 
assume that once a connection is established, all segments follow 
the same path. More precisely, the assumption is that links, routing 
tables, propagation delays, maximum buffer capacities, link MTUs, 
and other path properties are mostly static, with the only variable 
being the amount of other traffic filling links and buffers at any 
time. This leads to the “network-pipe” model, described by Jacob- 
son mi As demonstrated in figure |2(aj} in this model, y-axis dis- 
tances (pipe widths) represent link bandwidth, and x-axis distances 
(pipe lengths) represent time (queueing and propagation delays). 
The data stream flows through one set of pipes to the receiver, and 
acknowledgements flow through another set of pipes back to the 
sender. 

Based on the network-pipe model, Jacobson’s principles for con- 
gestion control can be understood as attempting to keep the net- 
work’s pipes full, without overfilling them. 

• To reach equilibrium, the sender should quickly probe the 
network for a capacity estimate. TCP’s slow start algorithm 
satisfies this need, and once this estimate is made, the con- 
gestion avoidance algorithm takes over, and future probing is 
much less aggressive. 

• A sender in equilibrium should follow the conservation of 
packets principle to avoid congestion. Conservation of pack- 
ets is the idea that to maintain equilibrium, a new packet is 
only put onto the network after an old packet has left the net- 
work, keeping a constant number of packets in flight. TCP 
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(a) Visualization of TCP segments and ac- 
knowledgments moving through a network 
path, using the network-pipe model 


Figure 2: Adapting the 



(b) The split-pipe model adaptation, in which 
a valve switches packet flow from one pipe to 
another at the time of a mobility event. 


:-pipe model to reflect mobility 


achieves this packet conservation through its ACK-clocking 
mechanism, sending new data upon receipt of acknowledge- 
ments for old data. 

When a mobile node moves during the course of a TCP connec- 
tion, the network path between the hosts changes in a way that is 
difficult to visualize using the standard network-pipe model. We 
propose an extension, illustrated in figure [2(b)] called the split-pipe 
model, which captures this behavior. In the split-pipe model, mo- 
bility between network attachment points corresponds to switching 
the valve between the top and bottom pipes. Using this model, 
we can re-examine Jacobson’s congestion control principles. Fig- 
ure 2(b) has been simplified by abstracting out the ACK-carrying 
pipes, to focus on the data-carrying pipes. In theory, changes to the 
ACK path could be serious as well. 

2.1 Problems with Soft Handoffs 

If the underlying mobility management scheme allows soft hand- 
offs, then for some period of time, acknowledgements for data seg- 
ments sent through the top pipe will be received. We call these stale 
acknowledgments. Stock TCP uses these stale acknowledgements 
both to clock out data segments that travel through the bottom pipe, 
and to increase its sending rate. This behavior is not in line with 
the packet conservation principle, as stale acknowledgements do 
not indicate that segments have left the bottom pipe, where new 
segments are sent. Nor should stale acknowledgements be used 
to increment the sending rate into the bottom pipe, as they repre- 
sent feedback about the top pipe’s state, and convey no informa- 
tion about the bottom pipe. Stale acknowledgments should be used 
to indicate successful transmissions and remove data from the re- 
transmission queue, but otherwise be ignored for the purposes of 
congestion control and clocking out new data. 

In addition to ignoring stale acknowledgments for congestion 
control purposes, the behavior of attempting to maintain the equi- 
librium achieved in the top pipe, after a change to the bottom pipe, 
is unwise for a number of reasons. If the bottom pipe, is much 
larger, or has more free space, then the conservative congestion 
avoidance strategy can waste this by leaving it unused. In the op- 
posite case, where the bottom pipe is much smaller than the top 
pipe, then using the old equilibrium state in the new pipe can lead 


to congestion losses. These problems are demonstrated quantita- 
tively in Section 31 For now, we argue from the model and prin- 
ciples that slow start should be re-initiated after the change to the 
new path, from the connection’s initial congestion window, and not 
the congestion window at the time of transition. 

2.2 Problems with Hard Handoffs 

Some network layer mobility protocols may cause up to an entire 
window of segments or acknowledgements to be lost. If this degree 
of loss occurs, then TCP senders may be forced to wait idly for a 
full retransmission timeout before beginning the process of repair- 
ing the losses and recalibrating the congestion window to the new 
network. The retransmission timeout is a rather long time frame 
for a sender with queued application data to pause for, typically 
representing several RTTs f2Tl (as measured in the old network 
before the transition). If a TCP sender has an amount of outstand- 
ing data that fills its congestion window, and acknowledgements 
for this data are lost due to the change in network paths, then this 
entire time is wasted. 

The RTO wait period is particularly a problem in wireless net- 
works because the RTO duration tends to be longer than when tra- 
ditional wired links are used. One reason for high RTO values in 
wireless networks is that they often use link layer retransmissions 
to mitigate the effects of high bit error rates [7J. Because of link 
layer retransmissions, the measured RTT varies significantly caus- 
ing the RTT-variance to increase. Since the RTO depends upon the 
RTT-variance, the wait periods tend to be rather large. Addition- 
ally, severe over-buffering of wireless links is a common practice, 
which leads to longer RTOs [9] [01. In a real EGPRS test network 
at Nokia, retransmission timeouts have been routinely observed af- 
ter handoffs between subnetworks. 

Since outstanding data on the old network path does not con- 
tribute to congestion on the new path, where the TCP connection 
has no in-flight data, then this outstanding data should not prevent 
new (acknowledgement-generating and RTO-avoiding) segments 
from being sent over the new path. The ability to send data on 
the new network allows acknowledgements to come back which 
will indicate whether or not losses occurred during the transition 
and need to be repaired, and in either case, will allow a wasteful 
timeout to be avoided. In this case, avoiding the RTO itself is a 
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more effective approach than trying to detect and correct for spuri- 
ous RTOs after the fact, as many techniques have been proposed to 
do [161123]. 

2.3 Invalid ss thresh After Handoff 

The congestion control state of a TCP connection includes a vari- 
able, ssthresh (for the slow start threshold), which sets the bound- 
ary congestion window between TCP’s exponential and linear in- 
creases in sending rate. When the congestion window is under 
ssthresh, TCP rapidly probes available capacity using slow start. 
When the congestion window reaches ssthresh , the more conser- 
vative congestion avoidance algorithm takes over. Initially, at the 
beginning of a connection, ssthresh is set to a high value. When a 
loss is first inferred via the fast retransmit mechanism, ssthresh is 
set to half of the present amount of outstanding data. After retrans- 
mission timeouts, TCP resets the congestion window to a single 
segment, uses slow start up to ssthresh and then enters congestion 
avoidance. 

Initially, the high ssthresh value allows the exponential increase 
strategy during slow start to operate until the network's limit is 
reached. After this point, ssthresh is always set to some previously 
attained rate, so slow start is never again used to probe for fresh 
network capacity, but rather to simply get up to a previously known 
“safe” speed. This strategy assumes that the amount of available 
capacity remains somewhat close to the previously estimated val- 
ues. With mobility between diverse networks, this may not be the 
case. Newly attached networks may offer multiple orders of mag- 
nitude in higher rates, which TCP congestion control will be unable 
to utilize. Particularly with long RTTs and high network capacities, 
the additive increase strategy is slow to explore higher rates. 

Consider the case of a TCP connection that begins while two 
hosts are connected via a 384 kbps link with 100 ms of one-way 
propagation dela>0. This scenario is designed to be simple for 
demonstration, not necessarily realistic. Such a TCP connection 
will have its ssthresh set to roughly 6 kB, assuming an RTT of 
around 250 ms, which is sufficient for keeping its congestion win- 
dow in the range to reasonably utilize this particular network. 

If, at some point, one host changes connection points, such that 
the new link (or path) between the two is identically configured 
as the old one, aside from the available capacity, which increases 
to 54 Mbps, keeping the stale ssthresh established on the old link 
prevents the new capacity from being efficiently used. To fully uti- 
lize the new network, the congestion window would need to reach 
nearly 1700 kB. Even with multiple kB segments, the linear march 
from 6 kB to 1700 kB would take an inordinate number of round- 
trip times. Figure[3]plots this time as a function of the ratio between 
RTT and segment size. Even with an RTT of only propagation de- 
lay (200 ms) and a segment size of 8 kB, this takes over 42 seconds. 
Using slow start, this time could be reduced to under 12 RTTs, or 
around 3 seconds. 

While the given example is somewhat contrived, similar real- 
world scenarios are not altogether inconceivable. For example, sys- 
tems supporting communications for space exploration or air traffic 
management may have such widely varying types of links available 
to them, and frequently transition connections between links due to 
fading, line-of-sight blocking, noise in a frequency band, or other 
link disturbances. 

The slow start threshold is a TCP state variable whose purpose 
is to prevent the large burst of losses that slow start can cause. The 
adjustment rules do not allow for rapid probing of newly available 


2 Throughout this paper, all link buffers are configured using the 
B = ( RTT x C)/y/n rule gj 
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Figure 3: Relation between segment size, RTT, and minimum time 
to reach 54 Mbps when ssthresh is 6 kB 



Figure 4: Effect of RTO wait period and stale ssthresh on conges- 
tion window, after a hard handoff. 


capacity after the initial estimation. Since the available capacity 
can significantly change with network layer mobility between dis- 
tinct types of networks; when transitions take place, the slow start 
threshold should be re-initialized to a large value to permit for rapid 
probing of available capacity in the new network. This is perfectly 
allowable under present congestion control principles, as it pro- 
duces the exact same effect as a new flow starting up. Figure [4] 
illustrates an example time benefit that can be achieved by avoid- 
ing an RTO and reseting ssthresh after a mobility event where more 
capacity becomes available. 

2.4 Network Design, Provisioning, and 
Stability 

We have assumed mobility events to be infrequent over the life- 
time of an individual connection, but within the entire network 
there may be many mobile hosts, each with several connections. 
While a single host’s congestion control behavior will certainly in- 
fluence the performance of its own connections and others sharing 
the same links, the design and stability of the network as a whole 
may be an issue as the number of mobile nodes or connections in- 
creases. 

Figure 5(a)| shows two connections, C i and C 2 that are termi- 
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(a) Set of routers that are affected by a path 
change. 


(b) System view when multiple connections 
cross subnet boundaries. 


Figure 5 : System View of Subnet Change 


nated at mobile nodes i?i and R2. At time t, Ci’s segments flow 
through routers X4 and x\ , but at time t + 8 , Ri moves from link 1 1 
to link Iq. The new path which segments take is through routers *4, 
£5, and xo . With soft-handoff support, x,\ tunnels segments for Ri 
to xo. The link between these two routers must be adequately pro- 
visioned to accept the sudden burst of tunneled traffic, which leads 
the design of the network to include expensive high-speed links be- 
tween access routers, which would otherwise not be needed. 

The tunneled segments from the soft-handoff will generate ac- 
knowledgements and cause data to be clocked out through the new 
path, where some of the routers (xo and x$) have not seen previous 
segments from the connection, and may already be carrying a mix 
of flows that can’t immediately accommodate the demands of C\. 
While xo handles soft-handoffs and could be specially designed 
for such situations, X5 could be a generic router with no relation to 
the portion of the network specifically designed for mobile nodes. 
Over-designing the edge networks and routers (like xo) only pushes 
the problem upstream to other routers (like xs). 

Some networkers have argued that this is really not a problem, as 
the core of the Internet is known to be well over-provisioned any- 
ways. To rely on this property is dangerous and potentially expen- 
sive. We cannot accurately extrapolate the current state of network 
utilization to the future, as history has shown that new applications 
and ways to use the network emerge and are adopted very quickly. 
Furthermore, the Internet protocol suite is used in other realms than 
the global Internet (for instance, military and space exploration net- 
works), which have different requirements and may not be as over- 
designed. We desire congestion controllers that behave reasonably 
across all potential paths, not just the kinds that are presently most 
likely on the Internet. 

The problem of network design becomes even more difficult, 
considering that in figure 5 (a)| connection C2 also sends segments 
through X5 and xo after R2 moves at time t+ 7. Even if the network 
could handle C 1, or if the disturbance from Ci were to subside af- 
ter a short period of time, another disturbance would occur from 
C2 some time later (7 — <S). Since the mobility of Ri and R2 may 
be independent, there is no way to ensure that 7 and 8 are suffi- 


ciently far apart for the network to handle. With even more mobile 
nodes, or more connections per mobile host, the overall stability of 
portions of the network could be at stake. 

With some additional knowledge of average connections from 
mobile nodes and frequencies of movement, the network design 
problem is still not easy, even at the edges or between the access 
routers that handle soft-handoffs. If S{U) is the set of mobile nodes 
connected to some link h, any of those nodes may become con- 
nected to other links, and any nodes from other links may become 
members of S(h). Figure [ 5 (bj 1 shows the relation between a net- 
work lo and N surrounding networks for the purpose of 

designing lo to accommodate mobility to and from each of the 
nearby networks. Not only would the soft-handoff links between 
all these networks be expensive, and likely redundant, but for cost- 
effectiveness, the provisioning would only be sufficient based on 
some estimates of average (or worst-case) motion between 1 0 and 
each neighbor and the number of new flows that start and old flows 
that stop as nodes stay in each network. Given that with wireless 
networks, the neighbor set can easily grow and that the system is 
already provisioned based on several dicey estimates, the future 
adequacy of the overall system design is questionable, even if it is 
sufficient at some point in time. 

Fixing end-host congestion control algorithms to respond to mo- 
bility events seems like a far more fruitful, and cheaper, approach 
than attempting to design the network infrastructure to accommo- 
date sudden changes in offered loads. This puts the onus of respon- 
sibility on the end hosts where mobility actually occurs and takes it 
off innocent links and routers. Losses at properly configured static 
links and routers are the fault of end hosts’ sending patterns, and 
can be more easily prevented by the end hosts than inside the net- 
work. 

2.5 Other Path Properties 

Aside from the congestion window and ssthresh variables that 
store estimated path state information, TCP also makes an estimate 
of the RTT. This RTT estimate is used to compute the retransmis- 
sion timeout. Because instantaneously measured RTTs may vary 
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widely due to network buffering for congestion, previous estimates 
contribute to the current RTT estimate at any given time. This is 
a desirable practice when the measured RTTs have only transient 
or insignificant differences due to queueing; however, if a recently 
measured RTT differs from the current estimate significantly due 
to a path change, using the standard RTT update strategy is a hin- 
drance. Given significant differences, convergence of the RTT es- 
timate to a value representative of the new path may be slow. Up- 
dating the RTT estimate based on stale acknowledgements can also 
lead to a poor estimate. 

An invalid RTT estimate makes the retransmission timeout either 
too long or too short, depending on the direction the RTT estimate 
is in error. If the RTT estimate is overly long for the new network, 
then the RTO timer is slow to fire and the amount of idle time be- 
fore retransmission is needlessly long. If the estimate is too short, 
then segments may be spuriously retransmitted, with the conges- 
tion window unnecessarily reduced. In either case, this is harmful 
to TCP throughput. Both overly conservative and overly aggressive 
RTOs can be mostly avoided in the case of mobility, though. If a 
mobile host can simply re-initialize its RTT estimate with the first 
available information it gets from a new path, then its RTO timer 
will be reasonably set. When a path change is known to have oc- 
curred, there is no logic behind letting old estimates from a defunct 
path cloud TCP’s judgment. 

To avoid IP fragmentation, some TCP implementations execute 
path MTU discovery algorithms, although this can be problematic 
Ifl5l . Since the path MTU can change when the path does, the 
discovery procedure should restart after mobility events. In ad- 
dition, other more experimental path properties that are measured 
by a particular TCP implementation should also be re-estimated. 
For example, some experimental TCPs use estimations of a path’s 
packet loss rate to alter congestion control behavior |[2lf51. In this 
case, biasing estimates in the new network based on data collected 
either in the old network or from stale acknowledgements could be 
troublesome. These types of considerations are not nearly as im- 
portant as reseting the congestion window, ssthresh, and avoiding 
RTOs, but not to be ignored. 

3. LIGHTWEIGHT MOBILITY DETECTION 
AND RESPONSE 

The Lightweight Mobility Detection and Response (LMDR) al- 
gorithm has been proposed within the IETF as a way of avoiding 
the TCP problems described in the previous section. LMDR is de- 
signed to be independent of the underlying mobility management 
protocol. LMDR’s only requirement is that a mobile node has some 
means of detecting its own mobility. In most cases, this require- 
ment is easily satisfied. For example, standard neighbor discovery 
f 1911 procedures may be sufficient for this purposqj 

Although a mobile node can detect its own mobility, its peers 
(e. g. the CN in figure [1) will often be unaware of this movement. 
Since a path change influences the congestion state in both direc- 
tions of the connection, a mobile node must somehow inform its 
remote peers of local mobility events. To achieve this, LMDR uses 
a TCP option, that is specified to be reliable, even in the case where 
both nodes simultaneously move. This is the “mobility detection” 
portion of LMDR, as described in detail in Section [3711 

3 In some cellular networks such as (E)GPRS networks, the mo- 
bility information is not only hidden from the transport layer but 
also from the IP layer. A path change in these networks will not 
be detected by simple techniques like neighbor discovery. How- 
ever, even in these networks it is possible to detect mobility events 
with the help of link layer protocols. The exact mechanism of how 
mobility events are detected is outside the scope of this document. 
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Figure 6: Wire-format of the LMDR TCP option 


Once a host is able to detect potential path changes, either by 
monitoring its own mobility, or by receiving an LMDR TCP op- 
tion, it can easily take corrective measures to address the problems 
sketched in Section [2] The “response” component of LMDR con- 
sists of performing these actions, and is detailed in Section 13.21 
We consider LMDR to be a “lightweight” mechanism for several 
reasons. First, it requires no additions to the network architec- 
ture, and no changes to existing infrastructure components. Sec- 
ond, LMDR does not burden the network with additional probes, 
heartbeat timers, etc. And finally, LMDR does not introduce any 
new protocols, but merely a simple TCP option whose processing 
occurs infrequently and requires only a small number of state vari- 
ables, and no expensive data structures or operations. 

3.1 Mobility Detection 

Detection of local mobility can be accomplished in numerous 
ways, depending on the underlying network layer and mobility 
management protocols. For example, there are neighbor, destina- 
tion, and ARP caches in various protocols that can be consulted to 
infer if a host has moved. Alternatively, changes in a default router 
or observation of router advertisements might be used. Ideally, the 
lower layer mobility code would propagate information on mobility 
events up the protocol stack via some form of message passing or 
data sharing, but this is not how current kernel implementations of 
protocols work. How a transport layer infers mobility information 
from lower layers is beyond the scope of this paper. 

A single host can unilaterally detect its own mobility and locally 
respond to it by fixing its own TCP state for the half-connection that 
it sends data over. This can be accomplished without any changes 
to the TCP wire protocol. However, if the half-connection in the 
reverse direction carries a large amount of data, the remote peer 
needs to be notified so that it can reset its TCP state. A new TCP 
option (shown in figure |6j is introduced for this purpose. 

As standard for multi-byte TCP options, the first byte identifies 
the type (whose value is presently unassigned), and the second byte 
gives its length — an invariant 3 bytes. The next two bits of the 
third byte are reserved for future use, and should be set to zero by 
senders and ignored by receivers. Possible uses for these two bits 
are left for future work. The remaining 6 bits are divided into two 
3-bit counters: CNTR and ECNT. 

As with other TCP options, use of the LMDR option is negoti- 
ated at startup time on the SYN and SYN-ACK segments. A host 
wishing to use LMDR places an LMDR option on its SYNs. If the 
remote host supports LMDR, it responds to received LMDR op- 
tions on SYNs, by placing an LMDR option on SYN-ACKs. Upon 
connection startup, CNTR is initialized to some random value, and 
ECNT is left uninitialized until the first CNTR value is received 
from the remote host. The ECNT field and variable are used to 
echo received CNTR values. Each time a host moves, it decrements 
CNTR (modulo 8), and advertises this by continuously transmitting 
LMDR options on its outgoing segments (both data-bearing and 
pure acknowledgements) until it receives back an LMDR option 
with an ECNT value that matches the local CNTR value. Upon re- 
ceiving LMDR options, a host sets its ECNT variable to the received 
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CNTR value. 

LMDR options are not sent on all segments. The only times 
when hosts need to send LMDR options are when they are inform- 
ing peers of their own mobility, or confirming the reception of a 
peer’s mobility notification. During normal exchange of data be- 
tween mobility events, there is no need to transmit LMDR options 
on segments. 


MN 


CN 


CNTR = 
ECNT = 


CNTR = 
ECNT = 


CNTR = 
ECNT = 


Time = T 

(MN and CN have an established 
TCP connection with the LMDR 
option negotiated) 


Time = T+l 
(MN moves to a new connection 
point, decrements its CNTR) 

segment with 
LMDR option 


ACK with LMDR 
option 


CNTR = 3 
ECNT = 5 


CNTR = 3 
ECNT = 5 


CNTR = 3 
ECNT = 4 


Figure 7: Example of MN notifying CN of a change in its attach- 
ment point 


The effectiveness of LMDR is limited to situations where end 
hosts are the only mobile nodes, and the network infrastructure re- 
mains fixed. If network path changes are not caused by the mobility 
of an end host, but through attachment to a mobile router, then the 
simplistic means we have described for detecting mobility will be 
ineffective. The LMDR techniques could still be used, only if there 
were some means for mobile routers to notify attached end hosts of 
mobility events. 

3.2 Mobility Response 

Upon detection of local or remote mobility, several actions need 
to be taken. We have previously discussed these, but lay them out 
again here in a specific order for clarity. 

1. Temporarily pause outgoing transmissions. Cancel the RTO 
and delayed acknowledgement timers. 

2. Update values of CNTR and ECNT as necessary. 

3. Record the highest sent sequence number as stale. Received 
acknowledgements for segments underneath stale will be con- 
sidered stale and ignored for congestion control, RTT estima- 
tion, and data clocking purposes. 

4. Reset the congestion window, ssthresh, RTO, RTT estimate, 
RTT variance, and other path properties as if this were a new 
connection. This automatically puts the connection into slow 
start territory, and allows at least one segment to be sent. This 


segment carries the LMDR option that either notifies the re- 
mote host of local mobility, or acknowledges receipt of an 
LMDR option generated by remote mobility. 

5. Resume normal outgoing transmissions 

Even, if use of the LMDR option is not successfully negotiated 
at connection startup, an individual host can still take most of the 
LMDR mobility response (everything but sending LMDR options) 
when it detects its own movement. This at least allows the half- 
connection it sources data on to better deal with rough path transi- 
tions. 

Since this mobility response involves slow starting from the ini- 
tial window, the impact of a mobile flow on the new network is the 
same as that of a totally new flow starting up, which even heav- 
ily congested networks are robust to. Furthermore, since slow start 
exponentially increases the congestion window, for a bulk-transfer 
flow, the amount of time required to reach the previous congestion 
window should be negligible. For more interactive flows, the tem- 
porary dip in the sending rate could be a problem, however few 
interactive applications that require smooth high rates use TCR 

4. SIMULATION-BASED EVALUATION 

In this section, we use simulations to show that stock TCP (with- 
out LMDR) can behave undesirably after mobility events, and that 
adding LMDR simultaneously mitigates the potential for both overly 
aggressive and overly conservative behaviors. 

4.1 Improving Friendliness to Competing 
Traffic 

Consider the case where a TCP connection endpoint moves such 
that in the new path, less capacity is available to it than in the pre- 
vious path. With an inappropriately high congestion window, the 
connection will likely cause and experience some packet losses. 
While TCP’s reaction to losses is a quick reduction in the conges- 
tion window, whether by half or down to a single segment, the re- 
duction is delayed until losses are inferred , and does not take place 
either immediately when or before they occur. Mobility events that 
result in substantial path changes can make previous congestion 
window estimates invalid. Delaying the congestion window reduc- 
tion until the first loss detection, rather than reducing it immedi- 
ately after the change in attachment points, can lead to temporary 
increases in loss rates observed by both the TCP flow and other 
competing traffic on the new path. 

Since TCP senses the losses caused by its inappropriate conges- 
tion window, and adjusts it in a manner that quickly converges to 
an acceptable level, a single flow transitioning between networks 
is not a long-term threat to the congestion level or stability of the 
end-to-end path. Transient bursts of packet loss are expected and 
coped with relatively well by modern transport protocols. How- 
ever, a node that moves once is likely to move again later, and if 
one node is allowed to move, than many nodes may also move. 
This makes the transient problem more serious, as it is bound to re- 
occur, perhaps frequently. This is harmful to the performance and 
fairness of TCP-like congestion control, the steadiness and friendli- 
ness of equation-based congestion control (like TFRC), and partic- 
ularly damaging to unreliable real-time protocols that rely on stable 
path conditions. 

Figure [8] shows the results from simulations^ where some num- 
ber of TCP flows establish themselves on a 10 Mbps path with 

throughout this paper, all simulations are run using the ns-2 net- 
work simulator, with TCP/Sackl senders, TCPSink/Sackl/Delack 
receivers, and all results averaged over 30 trial simulation runs. 
Simulation scripts are available from the authors upon request. 
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Figure 8: Increases in CBR loss rate due to temporarily unreasonable TCP congestion windows 
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Figure 9: Demonstration of LMDR effectiveness in reducing temporary congestion spikes 
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100 ms of one-way propagation delay. After 2 minutes, the flows 
are then moved to another identical path, where a constant bit-rate 
(CBR) flow is already consuming some of the new path’s capacity. 
Figure[8(a) plots the number of losses imposed on the existing CBR 
flow, during the first second after the transition, versus the number 
of TCP flows. The transitions are implemented such that there is 
no disconnection time between networks, and there is no loss of 
data segments, but all stale ACKs are lost (this is a hard handoff 
with the mobile node as data source). For comparison, the number 
of the constant bit-rate flow’s packets that are lost during a single 
second a full minute after the transition, when the TCP congestion 
windows have converged to appropriate values for the new path, is 
plotted as well in [8(b). The difference between each set of lines 
is due to the inappropriate TCP congestion windows immediately 
after the transition. 

One of the things this simulation shows us is that the problem 
is less severe when a large number of flows simultaneously make 
the path transition. This effect is due to the division of capacity be- 
tween the flows. If more flows utilize the same capacity, then each 
individual flow has a smaller congestion window. The smaller con- 
gestion windows are more likely to result in RTOs on losses, which 
causes them to be idle for much longer periods of time than a lesser 
number of flows, which have large enough congestion windows to 
repair most losses via fast retransmissions. Another important ef- 
fect of having more flows, is that the acknowledgements are less 
regularly spaced, causing the data segments that are lost and trig- 
ger congestion window reductions, to be sent less synchronously 
between flows. This allows flows to detect losses in a more stag- 
gered fashion, keeping the overall congestion level a bit lower and 
more stable than when all flows in unison blast out flights of pack- 
ets into a congested network. 

Figure [9] shows the results of the exact same simulations summa- 
rized in figured] only in this case, the TCP flows all use LMDR to 
rapidly adjust themselves to the new path. Comparing the results 
shown in figure[9]to those in figured] the number of losses imposed 
on competing smooth traffic in the second of time immediately after 
the transition is greatly reduced in all cases with LMDR, while the 
steady state behavior 60 seconds later is similar in both cases. With 
the 4 and 8 Mbps CBR flows, the raw number of packet losses was 
reduced by over 50% during the initial second after the transition. 
This makes the transition much less disruptive to existing traffic on 
the new network path, while attaining the same steady-state result. 

4.2 Faster Utilization of Newly Available 
Capacity 

In Section 2.31 we demonstrated how not reseting ssthresh can 
cause under-performance if a node moves into a new network path 
that can accommodate a much greater rate. Although it is fairly 
clear that reseting ssthresh in such a case allows for faster prob- 
ing of available capacity, we provide simulation results here as an 
example of the quantifiable gain that can be expected when using 
LMDR in such situations, and look at the impact on performance 
over several time-scales. Our simulation reproduces the scenario 
described in Section [2l3l where a mobile node moves from a point 
where 384 kbps is available, to a point where 54 Mbps is available, 
with the same round-trip latency. This simulation is repeated 30 
times with varying numbers of TCP flows simultaneously making 
the transition, and with both LMDR support, and unmodified TCP. 

Figure [Kjj illustrates the results of these simulations by plotting 
the improvement in an average flow’s throughput when LMDR is 
used by all connections compared to when it is not used by any of 
the connections. This is computed using the total throughput over 
various amounts of simulation time, with the transition between 


networks happening after 2 minutes. If less time after the transition 
is taken into account, then the LMDR advantage is more significant, 
as shown in figure [TO] This plots the gain in total throughput, as 
computed 30, 60, and 120 seconds after the transition. Gains are 
due to LMDR's much more rapid convergence (exponential versus 
linear) on the new available capacity. After stock TCP probes the 
newly available capacity, there is no difference in behavior between 
it and LMDR, and each reach nearly the same capacity. 
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Figure 10: Example throughput gain when using LMDR after mov- 
ing from 384 kbps link to 54 Mbps link 
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If we zoom-in to a time-scale covering only several RTTs after 
the transition, we can see that by resetting to the initial congestion 
window, LMDR may temporarily send more slowly than stock TCP 
(if the stock TCP isn’t in the midst of a retransmission timeout). 
This is quickly reversed though, and the temporary degradation 
in performance is a necessary product of taking the correct action 
based on congestion control principles derived from the split-pipe 
model in Section 2] 

From these example simulations, we see that LMDR can cause 
mobile connections to be less offensive to other traffic, and aid per- 
formance when transitions create a path with much greater capac- 
ity. The LMDR behavior is simultaneously advantageous for both 
resource conservation and high utilization, satisfying both the com- 
munity needs, by keeping the network stable, fair, and friendly, and 
selfish individuals, by providing higher performance when avail- 
able. 


4.3 Multiple Node, Multiple Network Tests 

To this point, the results we have presented have been from rather 
simplistic simulations, with flows changing networks simultane- 
ously. In this section, we introduce a slightly more complex simu- 
lation topology and scenario, in which multiple mobile nodes ran- 
domly move through multiple networks of differing uplink and 
downlink capacities. In this particular case, the results still indi- 
cate an average net gain from using LMDR, although it is more 
modest (on the order of several percent). 

FigureTTIillustrates the topology used in these simulations. Two 
corresponding nodes (CN1 and CN2) have TCP connections to 
three mobile nodes each (MN1 through MN6). The mobile nodes 
are distributed amongst three access routers (AR1 to AR3). Ini- 
tially, two mobile nodes connect to each access router, with mobil- 
ity between access routers occurring randomly, with each mobile 
node moving once ever 2 minutes on average. The access routers 
are connected to the corresponding hosts using links of variable ca- 
pacities (cl through c3), and connected to each other for tunneling 
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(c4 to c6). The simulator’s mobile IP support is used over dynamic 
links, which produces hard handoffs. 



Figure 11: Topology Used for Multiple Node, Multiple Network 
Tests 


ogy such that cl, c2, c3, and c6 were 500 Mbps, c4 was 5 Mbps, 
and c5 was 50 Mbps. This caused all the flows to start out with fast 
links, and then after mobility events, have their segments tunneled 
through links of possibly much lesser capacity. This is different 
from our topology where the MNs sourced data, as in that case the 
tunneling links were all of high capacity, but the access links var- 
ied. In this case, the results still show a positive average gain from 
a flow using LMDR, of 3.2%. The CDF is not presented here, but 
is very similar to that of figure [[2] except with the upper tenth per- 
centile representing lesser gains. This accounts for the decrease in 
the mean. 

For bidirectional traffic, we modified the link capacities with the 
topology again. In this case, cl and c4 were set to 500 Mbps, c2 and 
c6 to 5 Mbps, and c3 and c5 to 50 Mbps. This set of simulations is 
somewhat different from the others in that there can be congestion 
in both the data and acknowledgement paths. With this configu- 
ration, we observed individual flows gain an average of 8.5% in 
throughput, although there were outliers that experienced large de- 
creases. This further demonstrates that LMDR is not specifically 
designed to improve the performance of all flows, and may result 
in losses, but is gainful on average. 


We perform three different sets of simulations in this setup. In 
one set, the MNs source traffic, in another the CNs do, and in the 
final set, traffic is bidirectional. In each case, the link capacities cl 
to c6 are set to particular values to make the experiment interesting. 
Each set is run for 30 iterations with the same random seed used 
in both a fully LMDR-enabled situation, and a fully LMDR-less 
situation, with each simulation lasting 5 minutes. We record the 
number of unique user data bytes transferred by each TCP flow 
over this time period. 

In the case where the MNs alone source traffic, c3, c4, c5, and 
c6 were set to 500 Mbps, while cl was set to 5 Mbps, and c2 
to 50 Mbps. With this configuration, individual flows averaged a 
14% gain in throughput by using LMDR, in comparison to their 
counterparts with the same mobility pattern in the accompanying 
simulation that did not use LMDR. Figure [12] plots the cumula- 
tive distribution function of throughput improvements observed in 
these simulations. Despite the solid improvement in average per- 
formance, clearly LMDR did not always increase a flow’s through- 
put, and in many cases it accounted for a degradation. The sum of 
the throughputs in each simulation increased by 2.9%, on average. 
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Figure 12: Cumulative Distribution Function of Throughput Gain 
With MNs Sourcing Data 

When configuring the CNs to source data, we changed the topol- 


5. DISCUSSION 

As mentioned previously, even though TCP can maintain con- 
nections over transparent network layer mobility protocols, sim- 
ply maintaining a connection is not the same as providing an ef- 
ficient level of performance and acting as a good network citizen. 
TCP continues to function without LMDR, and perhaps in the nor- 
mal global Internet, the mobility scenarios we have shown to be 
problematic, will only rarely or never occur. Core networks may 
continue to be well-provisioned enough, that end-user demand and 
connectivity will limit the danger to the core’s congestion level and 
stability posed by mobility-induced TCP problems at the edge. In 
this case, LMDR is probably not crucial to the architecture. 

Unlike many other TCP extensions, LMDR is not explicitly in- 
tended to improve the throughput of TCP connections. Its purpose 
is to correct what we view as an oversight by the designers of trans- 
parent network layer mobility protocols. The Internet protocols are 
arranged in a stack, and changes to one layer should not be made 
without consideration of how these changes may affect higher lay- 
ers. LMDR assumes there is some way by which the network 
layer’s transparency can be reduced slightly so that the transport 
may know when local point of attachment changes occur. Since the 
transport layer is typically tasked with keeping estimates of end-to- 
end path properties, network layer protocols that knowingly change 
that path in a completely transparent way, are behaving negligently. 

Given the knowledge that a path change has occurred, LMDR’s 
behavior can be described as an attempt to take the most correct 
and conservative transport protocol behavior. As shown, LMDR is 
a better neighbor to competing traffic than stock TCP, when mov- 
ing into a congested network path. We have also shown cases where 
by reseting ssthresh and avoiding retransmission timeouts, LMDR 
can achieve better throughput than stock TCP. There may be cases 
where using LMDR actually reduces a flow's performance by some 
small margin, however, this is clearly acceptable given the signifi- 
cance of its positive impact in other cases. 

We have raised the point that the magnitudes of capacity differ- 
ences in some of the path transitions we've looked at is probably 
unrealistic for today’s Internet and common mobile devices. The 
IP protocol suite can be used in other environments than merely the 
Internet, though. Transitions between vastly different networks are 
not only possible, but highly likely for certain classes of military 
communications and NASA space-exploration missions, for which 
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TCP and IP may be used. Whether or not LMDR is needed for 
reasons of reducing congestion or aiding performance in the global 
Internet, it does not hurt in any way, and to not include it under the 
assumption that rare cases of problematic mobility scenarios will 
remain rare, is perhaps a mistake. 

6. CONCLUSIONS AND FUTURE WORK 

We have studied several problems TCP connections may expe- 
rience after mobility events, and introduced the LMDR procedures 
to correct these issues. Simulations have shown that LMDR is an 
effective technique for combating these problems and improving 
TCP performance in mobile environments. 

Other transport protocols have similar mechanisms to TCP’s for 
estimating various path state properties, and may experience simi- 
lar negative effects after path changes. The LMDR option for TCP 
offers no benefit to applications that do not use TCP as a transport. 
Other transport protocols may require adaptations of LMDR. For 
example, a “Reset Congestion State” option is present in an under- 
development version of the DCCP base specification. This option 
could be sent by a host after detecting its own mobility and reseting 
its own invalid path state estimates, to ask the remote host to do the 
same. 

We have mentioned that mobility of routers can cause similar 
path change problems as end host mobility, but that LMDR is help- 
less in this case. Some provisions for notification or detection of 
mobility inside the network path, and not just over links adjacent to 
the end hosts, would be beneficial in such cases, and could likely be 
easily incorporated into the LMDR detection facility. The LMDR 
response would likely be able to remain unchanged. 
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APPENDIX 

A. MOBILITY MANAGEMENT SCHEMES 

Although most network layer mobility schemes achieve similar 

basic results, there is substantial variation among these protocols. 

In this appendix, we provide a brief overview of a small sample of 

mobility management schemes. We have restricted our discussion 

to IETF protocols only, although similar technologies exist [5, 1], 

MIPv4 Mobile IPv4 hosts have static IP addresses. MIPv4 operation 
can be thought of as a coordination of three processes. First, 
a mobile host determines that it has moved from one network 
(home) to another (foreign), and in the new network, tig |nj)st 
obtains a care-of address (either by obtaining a new IP ad- 
dress on the foreign network or by locating a foreign agent). 
Second, the mobile node registers its care-of address on the 
new network with its Home Agent. The Home Agent is an 
indirection point on the network that the mobile node’s static 
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address belongs to. Third, as packets arrive on the home net- 
work addressed to the mobile node's static address, the Home 
Agent intercepts them and tunnels them to the mobile node's 
current care-of address. 

Several factors can slow the time between the node’s move- 
ment to a new network, and registration with the Home Agent. 
These include: detection of the network change (through router 
advertisements, etc), acquisition of a new address (via DHCP 
and duplicate address detection), authentication with the new 
network, and latency or packet losses when registering the 
care-of address with the Home Agent. During this time pe- 
riod, all packets sent to the mobile node’s static address will 
be routed to an old care-of address, and not to the mobile 
node’s current location. 

MIPv6 Basically, Mobile IPv6 works in a similar fashion to MIPv4. 
Unlike MIPv4, MIPv6 includes route optimization, which can 
be used to bypass the Home Agent and send packets directly 
from corresponding nodes to a mobile node. This requires 
a two-message exchange (one round trip) for authentication, 
called the return routability test. This always adds an RTTof 
delay before packets can be sent on the new path, which can 
result in a full congestion window of data being sent to a stale 
address and lost. 

The latency involved in establishing a new tunnel in MIPv6 
has motivated the design of fast-handover techniques that in- 
volve coordination with access routers. This can prevent the 
burst packet losses that may occur during stock Mobile IP 
handovers. 

HIP Mobility using the Host Identity Protocol is somewhat differ- 
ent, in that each node has another identifier that is indepen- 
dent from its IP address. Transports bind to these identifiers 
and the HIP layer takes care of mapping these to IP addresses. 


Changes to a node’s IP address are relayed to peers and cryp- 
tographically authenticated by the HIP layer. Like Mobile 
IP’s concept of the Home Agent, HIP also requires an indi- 
rection point, called the Rendezvous Server. The Rendezvous 
Server is only used to redirect the first packet to a mobile 
node. After this, nodes always send packets directly to each 
other. 

The update after an IP address change in HIP requires at least 
a round trip before packets can be sent to the new address. 
Since HIP identifiers are not used by routers, no mechanism 
similar to fast-handovers for MIPv6 is available for HIP. This 
means that mobility events always result in an RTTwhere any 
data transmitted to a mobile node is lost. 

NEMO The idea behind network mobility (NEMO) is to adapt the 
Mobile IP protocols to allow not just single hosts, but entire 
networks to be mobile, via the concept of a mobile router. 
This approach has many of the same advantages and disad- 
vantages as the Mobile IP protocols, and adds some additional 
complexity, in that it may be more difficult for hosts to detect 
their own mobility in a NEMO setting. The IETF’s NEMO 
working group is actively testing NEMO concepts and work- 
ing on producing a standard. 

Despite the many technical differences, we can broadly cate- 
gorize mobility protocols into two classes: hard handoff and soft 
handoff. Hard handoff protocols may cause a large number of 
in-flight packets to be lost as detection, configuration, and reg- 
istration occur after network transitions. MIPv4, MIPv6 (with- 
out fast-handover), and HIP are all hard handoff protocols. With 
fast-handover, MIPv6 is a soft handoff protocol, because it does 
not cause packets to the mobile node to be lost during transitions. 
NEMO handoffs could be made either hard or soft. By influencing 
packet loss, the distinction between hard and soft handoff protocols 
can significantly affect TCP’s behavior. 
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